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OC^ ' igy REMARKS/ARGUMENTS 

This is an appeal of the Final rejection dated January 30, 2006 of Claims 1-4, 6-10, 
12-17, 19-23, 25 and 27-49. A Notice of Appeal was timely filed on July 31, 2006. 
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I. REAL PARTY IN INTEREST 

^\The real party in interest in this appeal is the Assignee, Tandberg Telecom, AS. 



II. RELATED APPEALS AND INTERFERENCES 
Appellants' legal representatives and the Assignee are aware of no appeal or 

interferences which would directly affect or be directly affected by or have any bearing on 

the board's decision in this appeal. 



III. STATUS OF CLAIMS 
In the Final rejection dated January 30, 2006, Claims 1-10, 12-23, 25 and 27-49 were 

rejected under 35 U.S.C. §103(a) as being unpatentable over Kawai (U.S. Patent 6,137,485) 

in view of Comstock (U.S. Patent 5,692,073). 

In a telephone interview between the Examiner and Applicants' representative on 

October 24, 2006, the Examiner acknowledged that the Official Action contains a 

typographical error and that Comstock should be identified as U.S. Patent 6,704,769, not U.S. 

Patent 5,692,073. 

A clean copy of pending Claims 1-4, 6-10, 12-17, 19-23, 25 and 27-49 is attached as 
an appendix to this Brief. 

IV. STATUS OF THE AMENDMENTS 
Appellants have filed with this Appeal Brief an Amendment under 37 C.F.R. §1.116 

to materially reduce issues for appeal. This Amendment awaits disposition. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 
Claim 1 is directed to a system for managing video teleconferencing devices 
configured to exchange audio/video data. The system includes a management adapter (Fig. 1, 
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item 14) accessible to a user interface (Fig. 1, item 12), the management adapter having a list 
that identifies the video teleconferencing devices configured to exchange audio/video data, 
and a device access layer (Fig. 1, item 26) interfaced with the management adapter and the 
video teleconferencing devices. The device access layer represents the video 
teleconferencing devices as objects to support management of the video teleconferencing 
devices through the management adapter during set-up or conduct of an active video 
teleconference (Specification, page 13, lines 15-17). The video teleconferencing devices 
have plural video teleconferencing types, the device access layer representing each type of 
video teleconferencing device as an object class (Specification, page 13, lines 17-24; see also 
page 13, line 29 - page 14, line 10). Claim 15 is directed to a method substantially 
corresponding to the apparatus recited in Claim 1. Claim 27 is directed to an altemative 
embodiment of the method of Claim 15. 

Dependent Claim 2 recites that the device access layer represents the video 
teleconferencing devices as Management Beans. A Management Bean is a JAVA software 
construct (Specification, page 14, line 1 1 - page 15, line 11; see also item 60 of Fig. 3B). 
Claims 3, 4, 12, 13, 14, 16, 20, 23, 32 and 44 also recite Management Beans. 

Claim 20 is directed to a method for interfacing an SNMP management application 
with plural video teleconferencing devices having disparate native interface protocols. The 
method includes representing each video teleconferencing device as a Management Bean 
stored on a server (Specification, page 15, lines 27-30; see also Figs. 2-3), providing an 
SNMP management instruction for a video teleconferencing device to an SNMP adapter 
(Specification, page 17, lines 1-17; see also Figs. 2-3), communicating the SNMP 
management instruction using the SNMP adapter as a management bean client in 
communication with the server (Specification, page 17, Unes 1-17; see also Figs. 2-3), and 
communicating the SNMP management instruction fi-om the server through the management 
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bean representing the video teleconferencing device to the video teleconferencing device in a 
native protocol of the device (Specification, page 17, lines 1-17; see also Figs. 2-3), and 
sending audio/video data firom one of said plural video teleconferencing devices to another of 
said plural video teleconferencing devices (Fig. 3). Claim 25 is directed to a system 
substantially corresponding to the method of Claim 20, albeit without recitation of 
Management Beans. 

Claim 36 is directed to a system for managing a video network having plural video 
teleconferencing devices. The system includes plural objects, each object having attributes to 
represent a video teleconferencing network device, one or more lists of the attributes, one or 
more MIB having variables of the video teleconferencing network device (Specification, page 
20, lines 9-28; Fig. 4 items 68, 70, 72, 76 and 78)), and a MIB summation engine (Fig. 4, 
item 66) operational to select one or more attributes and one or more variables to dynamically 
create a MIB (Fig. 4, item 80; specification page 20, line 19 - page 22, line 22) for the video 
teleconferencing device during set-up or conduct of an active video teleconference. Claim 45 
is directed to a method substantially corresponding to the system of Claim 36. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The first issue is whether Kawai or Comstock disclose or suggest a device access 

layer representing each type of video teleconferencing device as an object class as recited in 
Claims 1, 15 and 27. 

The second issue is whether Kawai or Comstock disclose a management bean as 
recited in Claims 2, 3, 4, 12, 13, 14, 16, 20, 23, 32 and 44. 

The third issue is whether Kawai or Comstock disclose or suggest an SNMP 
management instruction for a video teleconferencing device as recited in Claims 20 and 25. 

The fourth issue is whether Kawai or Comstock disclose an MIB having variables of a 
video teleconferencing device or an MIB summation engine operational to select one or more 
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attributes and one or more variables to dynamically create an MIB as recited in independent 
Claims 36 and 45. 

VII. ARGUMENT 

A. Kawai and Comstock each fail to disclose or suggest a device access layer 
representing each type of video teleconferencing device as an object class as 
recited in Claims 1,15 and 27. 

Kawai discloses a variety of methods for remotely controlling cameras in a video 

teleconference, and providing an indication on a variety of video conference terminals for 

which terminal is controlling which camera. In Figure 3 of Kawai. reference nxmieral 60 

denotes an observer list field for displaying a list of observers who are observing the image 

picked up by the video camera 30 and transmitted onto the network 12. The list field 60 

displays the login name of the communication terminal of each observer. If there are a 

plurality of observers, the list field 60 displays a list of the login names of all of the 

observers. Reference numeral 62 denotes an operator field for displaying the name of an 

operator who is remote controlling the camera 30 at present.^ Kawai also discloses an access 

management process 78 that manages the remote control operations and image distribution 

operations of cameras 30 of all the video communications terminals 10-1, 10-2, 10-3 and 10- 

4 connected to the network 12. As acknowledged in the Official Action, Kawai does not 

disclose or suggest the use of objects. To cure this deficiency, the Official Action cites 

Comstock . 

Comstock discloses a system apparatus and method for managing media in a 
multimedia conferencing system according to media roles. Examples of media roles include 
"people" or "content." Page 2 of the Official Action asserts that Figure 1 of Comstock 
teaches the representation of devices as objects. Appellants traverse and note that Figure 1 is 
merely a diagram of a variety of devices connected to a network. The Official Action also 
* Kawai. column 4, lines 38-50. 
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cites column 3, lines 20-55 of Comstock. However, this citation also fails to disclose an 
object or any other type of control device or schema. This section of Comstock merely 
describes what types of devices may be connected together via a network, but does not 
disclose or suggest classifying devices as objects in software, let alone by object type. 

While not cited in the Official Action or Advisory Action, Appellants contend that the 
only possible portion of Comstock that might be remotely relevant to Appellants' claimed 
invention is the portion that describes call manager 135 and poUcy manager 136.^ The call 
manager 135 of Comstock merely implements well known video conferencing functionalities 
such as call initiation (using the H245 control protocol), codec selection and the like. The 
call manager 135 does not deal with "objects". 

Policy manager 136 operates to coordinate connection establishment and termination 
and may operate to control a video conferencing according to one or more policies. In 
general policies any rule, algorithm or combination or collection of rules and algorithms that 
may be applied to media streams in a video conference. This may include rules and 
algorithms that relate to assigning roles to media streams, as well as rules and algorithms that 
relate to handling media streams according to assigned roles. The poUcy manager 136 
implements a policy for displaying media stream bearing labels according to roles (people or 
content). The policy manager may permit a user to select, through a user interface 138, any 
number of people to display through a people display 154 and may allow the user to select 
specific participants for display. The policy manager may allow for establishment of a 
picture-in-picture display. The policy manager 136 may also require that only one content 
source may be selected at a certain time. The poHcy manager may further require that all 
participating terminals display content on their own local content displays. 



^ Comstock, colixmn 8, line 66 through column 10, line 16. 
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To manage the various policies, tokens are used to identify and control which terminal 
plays which role. Figure 3 of Comstock is a state diagram of token management by an 
arbitrating multipoint conference unit. Li step 200, the system is initialized. At step 202 a 
token holder variable is set to NONE, indicating that no participant in the video conference 
currently holds the token. When a request 208 is received for the token, the process transmits 
an acknowledgement 210 of the request 208 and sets the token holder variable to the 
requesting terminal as shown in step 212. At some point, the process may receive a request 
224 for the token while the process is in a token held state 214. If request 224 is from the 
current token holder an acknowledgement is transmitted 210 and the token holder variable is 
again set to the requester 212. If the request 224 is not from the current token holder, the 
process continues to step 228 where a withdraw request is transmitted to the token holder.^ 

Figure 4 of Comstock is a flowchart showing a process for initiating a video 
conference and uses roles according to the previously described concepts. After capabilities 
are exchanged and the logical channel is established, as shown in step 310, selected sources 
are coded and labeled. Source streams are coded using any suitable codex identified during 
the capabihty exchange. The streams are labeled according to the established or 
predetermined poUcy. A number of labels may be defined in an 8-bit label definition. The 
label may include designations of known media roles, for example 000: people; 001: content; 
010: mixed; Oil: any; and 100-1 1 1 : reserved. These labels may be appHed to media when 
the media is created. A media stream may be relabeled during use. 

However, the tokens of Comstock are only concemed with labehng displays of 
various media streams, and are not related to managing equipment via corresponding object- 
representations. However, assuming arguendo the classification of media streams into 
people or content types is creating objects, the media stream classification of Comstock is not 

^ Comstock, column 10, line 17 through column 1 1, line 45. 
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"representing each type of video teleconferencing device as an object class'^ as recited in 
Claim 1 or "dividing the video teleconferencing devices into types of video teleconferencing 
devices" or "establishing an object class for each type of video teleconferencing device" as 
recited in independent Claims 15 and 27. That is, the streams of Comstock are not labeled 
differently if they are related to an MCU, (a first type of video device) endpoint (a second 
type of video device) or other videoconferencing apparatus (a third type of video device). In 
fact, such a labeling would be nonsensical on Comstock . 

B. Kawai and Comstock each fail to disclose a management bean as disclosed in 
Claims 2, 3. 4. 12, 13, 14, 16. 20, 23, 32 and 44. 

A Management Bean is a JAVA software construct (Specification, page 14, line 11- 

page 15, line 11; see also item 60 of Fig. 3B). Page 3 of the Official Action states that 

column 5, lines 1-20 of Comstock discloses Appellants' claimed management bean. 

Appellants traverse and note that this portion of Comstock merely describes that rack 10 may 

include different hardware or software devices used in video teleconferences. A rack is, as 

shown in the corresponding figure, a cabinet and is not a Java Management Bean. Both a 

Real Networks compatible G2 encoder/streamer and a Windows Media codec are 

hardware/software interface devices, and are not inherently related to Java Management 

Beans. Similarly a generic directory server, conference scheduler, database server, 

authentication server, and a billing/metering system are not inherently related to Java 

Management Beans. A review of the entirety of Comstock (and Kawai) reveal no reference 

to Java Management Beans, or any other Java constmct. 

C. Kawai and Comstock each fail to disclose or suggest an SNMP management 
instruction for a video teleconferencing device as recited in Claims 20 and 25. 

Kawai and Comstock each fail to disclose or suggest any sort of SNMP instmctions, 
let alone providing a) an SNMP management instruction for a video teleconferencing device 
to an SNMP adapter; b) communicating the SNMP management instruction using the SNMP 
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adapter as a management bean client in communication with the server; and c) 

communicating the SNMP management instruction from the server through the management 

bean representing the video teleconferencing device to the video teleconferencing device in a 

native protocol of the device as recited in Claim 20. Similarly, Kav^ai and Comstock each 

fail to disclose or suggest an adapter in communication with the apphcation to accept SNMP 

instructions from the application for a video teleconferencing device; and an agent in 

communication with the adapter, the agent representing the video teleconferencing device as 

an object having attributes, wherein the adapter and agent cooperate to convert the SNMP 

instructions to the native protocol with the video teleconferencing device object attributes 

translated into requests to the video teleconferencing device in a native protocol of the video 

teleconferencing device during set-up or conduct of an active video teleconference, as recited 

in Claim 25. Lideed, the Official Action provides no indication where these features may be 

found in the applied references. 

D. Kawai and Comstock each fail to disclose or suggest "a MJB having variables of a 
video teleconferencing device" or *'an MIB summation engine operational to 
select one or more attributes and one or more variables to dvnamicallv create a 
MIB" as recited in independent Claims 36 and 45. 

Kawai and Comstock each fail to disclose or suggest any sort of MIB or MIB 

summation engine, let alone one or more MIB having variables of a video teleconferencing 

network device; and a MIB summation engine operational to select one or more attributes and 

one or more variables to dynamically create a MIB for the video teleconferencing device 

during set-up or conduct of an active video teleconference as recited in Claim 36. Similarly 

Kawai and Comstock each fail to disclose or suggest dynamically creating a MIB for the 

video teleconferencing network device from selected attributes of the object associated with 

the video network device; and accessing the dynamically created MIB with the SNMP 

apphcation to manage the video teleconferencing network device as recited in Claim 45. 
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CONCLUSION 

MPEP §706.02(1) notes that to establish a prima facie case of obviousness, three basic 
criteria must be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference (or references when 
combined) must teach or suggest all the claim Umitations. Also, the teaching or suggestion to 
make the claimed combination and the reasonable expectation of success must both be found 
in the prior art and not based on Applicants' disclosure. In re Vaeck, 947 F.2d 488, 20 
USPQ2d 1438 (Fed. Cir.1991). Without addressing the first two prongs of the test of 
obviousness. Applicants submit that the Official Action does not present a prima facie case of 
obviousness because both Kawai and Comstock fail to disclose a variety of features recited in 
Applicants' independent and dependent claims. Thus, Appellants request that the rejection 
applied under 35 U.S.C. §103(a) to Claims 1-4, 6-10, 12-17, 19-23, 25 and 27-49 be 
REVERSED for the above-noted reasons. 

Respectfully submitted, 

OBLON, SPIVAK, McCLELLAND, 
MAIER & NEUSTADT, P.C. 
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VIII. CLAIMS APPENDIX 

1 . A system for maaaging video teleconferencing devices configured to exchange 

audio/video data, the system comprising: 

a management adapter accessible to a user interface, the management adapter having 
a Ust that identifies the video teleconferencing devices configured to exchange audio/video 
data; and 

a device access layer interfaced with the management adapter and the video 
teleconferencing devices, the device access layer representing the video teleconferencing 
devices as objects to support management of the video teleconferencing devices through the 
management adapter during set-up or conduct of an active video teleconference, wherein the 
video teleconferencing devices have plural video teleconferencing types, the device access 
layer representing each type of video teleconferencing device as an object class. 

2. The system of Claim 1 wherein the device access layer represents the video 
teleconferencing devices as Management Beans. 

3. The system of Claim 2 wherein each video teleconferencing device communicates 
with the network through one of plural protocols, the Management Bean for a video 
teleconferencing device communicating with the video teleconferencing device in the 
protocol associated with the video teleconferencing device. 

4. The system of Claim 3 wherein the Management Beans communicate with the 
management adapter using a common protocol. 

5. (Canceled). 
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6. The system of Claim 1 wherein a video teleconferencing device belongs to plural 
video teleconferencing types, the device access layer representing the video teleconferencing 
device as plural objects, each of the plural objects belonging to a class 5 corresponding to the 
plural video teleconferencing types. 

7. The system of Claim 1 wherein a video teleconferencing device type comprises an 
endpoint type. 

8. The system of Claim 1 wherein a video teleconferencing device type comprises an 
MCU type. 

9. The system of Claim 1 wherein a video teleconferencing device type comprises a 
gatekeeper type. 

10. The system of Claim 1 wherein a video teleconferencing device comprises a 
gateway type. 

11. (Cancelled). 

12. The system of Claim 1 wherein the device access layer comprises: 

a Management Bean server having Management Bean objects that correspond to the 
video teleconferencing devices, each Management Bean object encapsulating attributes that 
support access to a video network device. 

13. The system of Claim 1 wherein the video teleconferencing devices comprise: 
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one or more of plural device types, each device type having a common interface 
defined by a Management Bean class. 

14. The system of Claim 13 further comprising: 

first and second video teleconferencing devices interfaced with the device access 
layer, the first and second video teleconferencing devices having a common device type 
represented by a common Management Bean class, the first video network device 
communicating with a first Management Bean by a first format, the second video device 
communicating with a second Management Bean by a second format, the first and second 
Management Beans communicating with the management adapter by a common format. 

15. A method for communicating with first and second video teleconferencing 
devices configured to exchange audio/video data and having corresponding first and second 
commimication formats, the method comprising: 

dividing the video teleconferencing devices into types of video teleconferencing 
devices; 

establishing an object class for each type of video teleconferencing device; 

interfacing with a management platform through a management interface format to 
identify the video teleconferencing devices; 

associating the first video teleconferencing device with a first object and the second 
video teleconferencing device with a second object; 

translating communication to the first video teleconferencing device with the first 
object firom the interface format to the first communication format; 

translating communication to the second video teleconferencing device with the 
second object from the interface format to the second communication format; and 
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sending audio/video data from one of said first and second video teleconferencing 
devices to another of said first and second video teleconferencing devices. 

16. The method of Claim' 15 v^herein the first and second objects comprise 
Management Beans. 

17. The method of Claim 15 wherein the management interface format comprises 

SNMP. 

18. (Canceled). 

19. The method of Claim 15 wherein each type of video teleconferencing device has 
a common interface for exchanging data between an external interface and objects of the 
class associated with the type of video teleconferencing device. 

20. A method for interfacing an SNMP management application with plural video 
teleconferencing devices having disparate native interface protocols, the method comprising: 

representing each video teleconferencing device as a Management Bean stored on a 

server; 

providing an SNMP management instmction for a video teleconferencing device to an 
SNMP adapter; 

communicating the SNMP management instruction using the SNMP adapter as a 
management bean client in communication with the server; and 
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communicating the SNMP management instruction from the server through the 
management bean representing the video teleconferencing device to the video 
teleconferencing device in a native protocol of the device; and 

sending audio/video data from one of said plural video teleconferencing devices to 
another of said plural video teleconferencing devices. 

2 1 . The method of Claim 20 further comprising: 

associating the video teleconferencing device receiving the SNMP management 
instruction with an IP address; and 

communicating a second SNMP management instmction to the video 
teleconferencing device with the IP address. 

22. The method of Claim 20 further comprising: 
listing the video teleconferencing devices in a MIB; and 

associating the video teleconferencing devices with IP addresses with the SNMP 
adapter. 

23. The method of Claim 20 fiirther comprising: 

communicating between the management bean client and the server with standardized 
attributes defined for each video teleconferencing device. 



24. (Cancelled). 
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25. A system for interfacing plural video teleconferencing devices with an 
application through an SNMP interface, the plural video teleconferencing devices having 
disparate native protocols, the system comprising: 

an adapter in commxmication with the application to accept SNMP instructions from 
the application for a video teleconferencing device; and 

an agent in commimication with the adapter, the agent representing the video 
teleconferencing device as an object having attributes, 

wherein the adapter and agent cooperate to convert the SNMP instructions to the 
native protocol with the video teleconferencing device object attributes translated into 
requests to the video teleconferencing device in a native protocol of the video 
teleconferencing device during set-up or conduct of an active video teleconference. 

26. (Cancelled). 

27. A method for managing a video network having plural video teleconferencing 
devices, the method comprising: 

dividing the video teleconferencing devices into types of video teleconferencing 

devices; 

establishing an object class for each type of video teleconferencing device; 
representing each of said plural video teleconferencing devices as an object having 
attributes; 

communicating management instructions to the objects of the plural video 
teleconferencing devices; 

translating object attributes of the commimication instructions into device-specific 
instructions to manage one or more of the plural video teleconferencing devices; and 



vi 



Application No, 10/0?9,932 

Reply to Office Action of January 30, 2006 

sending audio/video data from one of said plural video teleconferencing devices to 
another of said plural video teleconferencing devices. 

28. The method of Claim 27 further comprising: 

Usting the attributes of an object that represents a video teleconferencing device; and 
selecting one or more attributes to create a MIB for the video teleconferencing device. 

29. The method of Claim 28 further comprising: 

selecting one or more variables from one or more pre-existing MIBs associated with 
the video teleconferencing device for inclusion with the created MIB. 

30. The method of Claim 28 wherein the created MIB cooperates with a management 
application for communicating management instructions to the object associated with the 
video teleconferencing device. 

3 1 . The method of Claim 30 wherein the communication instructions comprises 
SNMP management instructions. 

32. The method of Claim 3 1 wherein the object comprises a management bean. 

33. The method of Claim 28 wherein the created MIB consists of read-only variables. 

34. The method of Claim 28 wherein the created MIB comprises variables for a 
restricted set of users. 
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35. The method of Claim 27 wherein the device specific instructions comprise non- 
SNMP instructions. 

36. A system for managing a video network having plural video teleconferencing 
devices, the system comprising: 

plural objects, each object having attributes to represent a video teleconferencing 
network device; 

one or more lists of the attributes; 

one or more MIB having variables of the video teleconferencing network device; and 
a MIB summation engine operational to select one or more attributes and one or more 

variables to dynamically create a MIB for the video teleconferencing device during set-up or 

conduct of an active video teleconference. 

37. The system of Claim 36 wherein the created MIB comprises a structure 
associated with a predetermined and restricted set of users. 

38. The system of Claim 37 wherein the structure comprises a tiered folder structure. 

39. The system of Claim 36 wherein the created MIB comprises read only variables. 

40. The system of Claim 36 further comprising: 

a management application associated with the video network and operational to 
manage the video teleconferencing devices. 
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41. The system of Claim 40 wherein the management application comprises an 
SNMP application. 

42. The system of Claim 41 wherein the created MIB cooperates with the 
management application to manage the video teleconferencing network device. 

43. The system of Claim 42 wherein the object translates instructions from the 
management appUcation to a protocol native to the network video teleconferencing device. 

44. The system of Claim 43 wherein the object comprises a management bean. 

45. A method for managing disparate video teleconferencing devices with an SNMP 
application, the disparate video teleconferencing devices having disparate native protocols, 
the method comprising: 

representing the disparate video teleconferencing devices as objects having attributes, 
an object translating instructions from the SNMP application to a native protocol of a video 
teleconferencing network device associated with the object; 

dynamically creating a MIB for the video teleconferencing network device from 
selected attributes of the object associated with the video network device; 

accessing the dynamically created MIB with the SNMP application to manage the 
video teleconferencing network device; and 

sending audio/video data from one of the video teleconferencing devices to another 
video teleconferencing device. 

46. The method of Claim 45 wherein dynamically creating fiirther comprises: 

ix 
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dynamically creating the MEB from selected variables of pre-existing MIBs associated 
with the video teleconferencing network device. 

47. The method of Claim 45 further comprising: 

creating a translator table to associate the attributes with the dynamically created 

MIB. 

48. The method of Claim 45 wherein the SNMP application comprises HP 
Openview. 

49. The method of Claim 45 wherein dynamically creating the MIB further 
comprises: 

selecting attributes for inclusion in the MIB to customize the MIB for a specific user. 
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IX. EVIDENCE APPENDIX 

Not applicable. 
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X. RELATED PROCEEDINGS APPENDIX 

Not applicable. 
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